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Demand servicing attempts to correct existing overload conditions 
in the trunk network in a timely and cost-effective manner. The 
demand servicing procedures presented in this paper achieve this 
goal by taking actions that have minimal effect on the existing 
network configuration, account for the statistical nature of the traffic 
measurements, and follow the network design objectives. In compar- 
ison to existing methods, these procedures should reduce unnecessary 
servicing activity and improve the consistency between demand ser- 
vicing and planned servicing. 

I. INTRODUCTION 

Trunk network administration is composed of two major operations, 
planned servicing and demand servicing. Together, they determine the 
quantities and locations of interoffice trunks required to maintain a 
reasonable balance between network service and cost. Planned serv- 
icing provides circuits, using forecasts of demand made on a yearly 
basis. Demand servicing uses recent traffic measurements to detect 
and correct existing service problems. Because the Bell System trunk 
network represents a multi-billion dollar investment in equipment, 
personnel, and operation support systems, it is important that these 
functions be cost-effective and that they be performed efficiently. 
This paper describes recently developed procedures for demand serv- 
icing the trunk network. 

Demand servicing compensates for the effects of forecast errors on 
the planned network. Its main function is to detect the need for trunk 
group augments when service problems develop, and to take corrective 
action in a timely and cost-effective manner. In general, demand 
servicing is not concerned with disconnecting trunks in excess of 
current demand, since the removal of excess trunks is a part of the 
planned servicing function, which makes such decisions on the basis of 
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the year-to-year trunk forecast. Demand servicing represents a mini- 
mal adjustment necessary to restore service, rather than a complete 
reconfiguration of the network. 

The demand-servicing procedure described in this paper is designed 
for implementation as a new feature in the Trunk Servicing System 
(tss), a standard software tool used by Bell System operating compa- 
nies to monitor the performance of the trunk network. It represents an 
integral part of an overall plan for network administration. 1 

Section II of this paper reviews the fundamentals of trunk network 
design and introduces some of the problems to be considered. Section 
III discusses the demand-servicing policy objectives that motivated 
the approach taken in the design of the servicing procedure described 
in Sections IV and V. 

II. BACKGROUND AND MOTIVATION 

This section reviews the fundamentals of trunk network design and 
administration and introduces the key issues involved in this study. 

2. 1 Statistical nature of demand servicing 

The trunk servicer relies on traffic measurements to monitor net- 
work service and decide on corrective action when overload conditions 
are detected. To illustrate the statistical nature of this process, consider 
the simple, two-node network shown in Fig. la. The trunk group 
joining end offices A and B provides the only route for calls originating 
at A and destined for B. Such an "only-route" trunk group is sized 
according to an average blocking criterion, where blocking refers to 
the fraction of calls which arrive, but fail to find an idle circuit to their 
destination. The service objective for an only-route trunk group is 0.01 
average blocking in the time-consistent busy hour of the busy season. 

Using a forecast of traffic anticipated in the next busy season, 
planned servicing provides sufficient circuits to carry the expected 
traffic at the 1-percent blocking objective. To monitor trunk group 
service, the statistic B n = l/« £"=i #« is computed for the busy hour, 
where fi, represents the fraction of calls blocked in the ith day of an n- 
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Fig, i — ( a ) Only-route trunk group, (b) Alternate-routing network. 
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day study period.* Because of the finite number of days in the sample 
and the finite (1-hour) measurement interval each day, the average 
blocking will deviate from the 0.01 objective even when the group is 
correctly sized. 1 

Because of the importance of maintaining good service and the 
reluctance to disconnect trunks in excess of current demand, overre- 
action to these statistically volatile estimates can lead to unnecessary 
trunk group augments and higher-than-necessary levels of reserve 
capacity. Thus, it is important that the trunk servicer be provided with 
statistically reliable procedures for monitoring network service. 

2.2 Network considerations 

The demand servicing problem is considerably more difficult in a 
complex network environment. To understand the issues involved, we 
first review the fundamental principles of trunk network design. 

For reasons of economics, most end-office pairs are connected by a 
complex network that allows for the alternate routing of calls, rather 
than the simple only-route trunk group described above. Consider, for 
example, the network shown in Fig. lb. Calls originating at A and 
destined for B are first offered to the primary high-usage (ph) group 
AB. Failing to find an idle circuit, the call is then alternate-routed to 
the intermediate high-usage (ih) group AD. If an idle circuit is avail- 
able, the call is switched at D to its destination; otherwise, it is again 
alternate-routed to the final group AC. If an idle circuit is available, 
the call then proceeds to search for a path to B. If it is not possible to 
establish a path from source to destination, an "all trunks busy" signal 
(usually a recorded message or a fast busy signal) is given to the calling 
party, who must retry at a later time. 

Note that two types of trunk groups are shown here. Final groups 
(represented by solid lines) are sized for the same 0.01 average blocking 
objective described above for only-route groups. Also, note that as long 
as blocking is low on the final groups, calls originating at office A have 
a high probability of completion. 

High-usage trunk groups (represented by dashed lines) are usually 
designed for a much higher rate of overflow. Such a group is sized to 
balance the incremental load-carrying costs between its direct and 
alternate routes. 

For demand servicing in an alternate routing network, the following 
questions must be answered: 

(i) Are the traffic measurements on a trunk group consistent with 
the group's service objective, or are additional circuits required? 



* A 20-day study period consisting of four consecutive business weeks is recom- 
mended, although smaller samples frequently are obtained. 
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(ii) If corrective action is to be taken, which groups in the network 
should be augmented? 

(Hi) How many trunks should be added? 
The development of a trunk demand servicing policy that effectively 
addresses these issues is described in the remainder of this paper. 

III. DEMAND SERVICING POLICY OBJECTIVES 

The goal of demand servicing can be stated simply: Restore objective 
network service in a timely and cost-effective manner. This goal can 
be accomplished by a servicing policy designed to achieve the objec- 
tives discussed in this section. 

3. 1 Account for the variability of traffic estimates 

We have already seen (Section 2.1) how performance statistics based 
on traffic measurements are used to monitor network service. To avoid 
unnecessary trunk group augments and their associated costs, allow- 
ance must be made for the statistical variability of these estimates. 
Conversely, it is also important to detect poor service when such 
conditions exist. Thus, demand servicing rules must account for this 
variability to maintain a reasonable balance between cost and service. 

3.2 Minimize network activity 

Demand servicing action is required only when planned servicing 
fails to provide acceptable network service. It is important that this 
restoration of service be carried out quickly. Also, the need for the 
equipment required to provide the additional circuits probably has not 
been anticipated by the trunk forecast, the basic input to the equip- 
ment planning process. Therefore, these circuits may be more difficult 
to obtain. For these reasons, demand servicing should result in a 
minimal amount of network activity, both in the number of groups 
affected and in the number of additional circuits required to restore 
service. 

Since the blocking experienced by traffic originating from a network 
cluster* is ultimately determined by the blocking on the final trunk 
group, it is only necessary to demand-service a network cluster when 
the blocking on the final group is significantly greater than the 0.01 
service objective. Also, a high-usage group in an overloaded cluster 
should only be considered if it is contributing excess overflow traffic to 
the overloaded final. 

To summarize, we attempt to minimize the number of trunk groups 
affected by demand-servicing action by focusing on the overloaded 



* A network cluster consists of all high-usage trunk groups which originate at a 
common switching office and overflow to a common final trunk group. See Fig 2. 
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Fig. 2 — Example network cluster. 

network cluster final and those subtending high-usage groups contrib- 
uting to the high-blocking conditions. 

3.3 Service low in the network 

When a significant service problem has been detected on the final 
group of a network cluster, the group's blocking can be reduced by 
either 

(i) Adding trunks to the final. 

(ii) Reducing the load offered to the final by augmenting subtending 
high-usage groups, thus reducing their overflow. 

(Hi) Some combination of the above. 
Although it may appear that augmenting the final is the easiest way 
to restore service, there are several reasons for avoiding this type of 
action. 

We first consider the immediate effects of routing extra traffic via 
the alternate-route final rather than on the direct high-usage groups. 
As an overflow call rises in the network hierarchy, its path tends to 
become longer and to involve more switching. Thus, it is usually more 
expensive to carry and complete a multi-switched call rather than a 
direct call. Also, traffic carried on the lower levels of the network has 
less chance to interact with (e.g., block) other traffic in the system. 
Therefore, when demand servicing is required, trunks should be added 
to the groups that are currently underprovided, based on economic 
engineering considerations. 

Now consider the long-term effects of servicing exclusively high in 
the trunking hierarchy, e.g., the final. The result of this practice is that 
the final is actually overprovided by engineering standards, while high- 
usage groups are undersized. Thus, the yearly planned servicing proc- 
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ess would likely stimulate considerable rearrangements, representing 
both capital costs for equipment and significant administrative and 
labor expenses, in order to restore the network to a minimum-cost 
configuration. 

These considerations motivate a servicing policy that attempts to 
resolve the service problem at the lowest level of the trunking hierarchy 
consistent with the excess traffic causing the overload. 

3.4 Implement in tss 

The demand-servicing algorithm developed in this study was de- 
signed for implementation in the current tss system. This imposed 
constraints on both the type of information available and the way the 
algorithm would be implemented (i.e., batch rather than interactive 
processing). 

IV. SERVICING THRESHOLDS 

As we have already seen, an understanding of the statistical varia- 
bility of the traffic measurements that drive the demand servicing 
process is essential to the formulation of an effective servicing policy. 
In this section, we use previous work that quantifies this variability to 
develop statistical tests for detecting overloaded groups. 

4. 1 Thresholds of acceptable blocking for grade of service trunk groups 

For trunk groups sized for an average blocking objective,* the key 
statistic used to monitor service is the observed blocking B n over an n- 
day study period. Simulation studies and analysis by Neal 1 have 
determined the distribution of this statistic. The distribution depends 
on the number of trunks in the group, the number of days in the 
average, and the characteristics of the call arrival process — the mean 
load a, its within-hour variation or peakedness z, and its level of day- 
to-day variation <p. Figure 3 shows the average blocking distributions 
of a correctly engineered grade-of-service trunk group for both 10- and 
20-day study periods. 

Given the distribution of B n , it is possible to develop a simple 
statistical test to decide whether the measured average blocking is 
significantly greater than the 0.01 objective. The test uses athreshold 
or upper bound B u of acceptable observed blocking. When B n exceeds 
B u , we decide to take corrective action; otherwise, the measured 
blocking is acceptable and no action is taken. In this way, the upper 
bound B u defines the acceptable deviation from the service objective. 

The choice of the threshold B u is designed to achieve a reasonable 



* Such trunk groups are called "grade-of-service" groups. These include the only- 
route and final groups previously discussed. 
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Fig. 3 — Variability of measured blocking. 



balance between two types of servicing errors. False alarms, or Type 
I errors, occur when the measured blocking B n exceeds the threshold 
even though the group is correctly sized. Misses, or Type II errors, 
occur when the group is overloaded, but the measurement falls below 
the threshold and the problem is not detected. As we can see in Fig. 4, 
raising the threshold decreases the false-alarm probability but in- 
creases the miss probability. Although we have not quantified the 
costs associated with these errors, relative differences between the two 
can be used to establish performance criteria. 

Each false alarm results in the unnecessary expenditure of both 
capital and labor on an emergency basis. Because of the lead time 
required to react to a service problem (typically, several weeks to a 
few months after it is detected), it is possible that the busy season may 
have passed by the time circuits can be added. Thus, the trunk servicer 
should be reasonably certain that a significant problem exists before 
issuing an order for additional circuits. This means that the false- alarm 
probability should be fairly small, i.e., a few percent. 

Conversely, a miss occurs when the underlying true mean blocking 
exceeds the objective, but the realized blocking (i.e., the blocking 
experienced by the customer) falls below the threshold B u . However, 
if a real service problem is missed in one study period, it may still be 
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Fig. 4 — False-alarm and miss probabilities. 

detected in subsequent study periods. For these reasons, misses are 
relatively less serious than false alarms. 

Guided by these considerations, the following performance criteria 
were selected for determining the blocking thresholds: 

( i) A false alarm probability < 0.025. 

(ii) A miss probability < 0.10 when the group is overloaded to a 
0.05 blocking level. 

These criteria apply to study-period averages based on at least 15 
days of valid measurements, which are classified as A-quality data in 
the tss system. 

If By is the 0.975-quantile of the observed blocking distribution for 
a correctly sized group, then any B u > Bi satisfies condition (i). If B 2 
is the.O.lO-quantile of the blocking distribution for a group with 5- 
percent mean blocking, then any B u < B 2 satisfies condition (ii). Thus, 
if B\ < B 2 , it is possible to satisfy both criteria. 

For all but the smallest trunk groups (i.e., fewer than eight trunks), 
B\ < B 2 and both criteria may be satisfied. The thresholds selected for 
these groups are shown in Table I. They depend only on trunk group 
size and satisfy both criteria over the range of traffic conditions (values 
of z and <\>) encountered in practice. For the smallest trunk groups, the 
thresholds satisfy condition (i) only. 

For study periods with fewer than 15 days of data, it was generally 
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not possible to satisfy both criteria. To avoid the unnecessary servicing 
of trunk groups based on the more volatile estimates derived from 
these smaller samples, the thresholds of acceptable blocking are larger 
and satisfy condition (i) only. In this way, the trunk servicer, who is 
responsible for providing good service, is also encouraged to base his 
servicing decisions on high-quality data. Costly decisions which cannot 
be justified from the data are avoided. 

4.2 Thresholds for high-usage groups 

This section develops trunk estimate thresholds for high-usage 
groups which complement those developed in the previous section for 
grade-of-service groups. 

A high-usage trunk group sized to balance the incremental load- 
carrying costs of the direct and alternate routes has its load carried on 
the last trunk equal to its economic ccs (eccs) value. 3 Based on this 
criterion, a group's offered load and load characteristics estimated 
from study period traffic measurements are used to compute the 
number of trunks required, cr, to achieve this economic balance. As is 
the case for grade-of-service groups sized for an average blocking 
objective, the statistical variability of these trunk estimates must also 
be taken into account. 

This variability has been quantified by Hill, 2 who developed a 
normal approximation to the distribution of cr. Using those results, it 
is possible to derive thresholds of acceptable high-usage trunk esti- 
mates that satisfy specified criteria. Specifically, given the standard 
deviation <j c - h of cr (see the appendix) and an objective false-alarm 
probability a, the threshold for considering servicing action on a high- 
usage group with ci trunks in service is C/ + k a -o c ' H , where k a depends 
only on a and is commonly tabulated. 4 Thus, it remains to specify only 
the false-alarm probability a. 

While it is important to prevent false alarms, it is also important to 
detect overloaded groups. As we showed in Section 4.1, these are 

Table I — Thresholds of acceptable measured blocking for grade-of- 
service trunk groups (c = number of trunks in group, N = number of 

days in average) 
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conflicting objectives. Consequently, the mutual effects of the false- 
alarm and detection probabilities must be considered. 

Recall that one of the demand servicing objectives is to identify the 
source of overload conditions and resolve the problem as low in the 
network as is justified. Therefore, when overload conditions are de- 
tected on the cluster final due to undersized high-usage groups lower 
in the network, it is important that these groups contributing to the 
problem be identified and serviced. Thus, the choice of false-alarm 
probabilities for high-usage groups should provide adequate probabil- 
ities of detection. 

Detection probabilities are a function of the degree of overload. 
Recall that the thresholds of acceptable service for finals were designed 
to detect groups having 0.05 blocking with at least 90-percent proba- 
bility. Typically, 0.05 blocking occurs when the offered load is approx- 
imately 25 percent larger than the design load. Thus, 0.05 blocking on 
the final can occur if the overflow from all the subtending groups 
increases by 25 percent; accordingly, the high-usage detection proce- 
dure should identify groups with 25-percent excess overflow. 

Similarly, an increased load to the final of roughly 15 percent results 
in 0.03 blocking. Hence, if the detection process identifies half the 
groups with 25-percent overloads and they are augmented, the new 
load to the final will have an expected blocking of less than 0.03, and 
the final-group blocking will most likely be acceptable. 

To select the upper limit of acceptable estimates, loads which 
produced approximately 25-percent excess overflow over a wide range 
of trunk-group size, peakedness, level of day-to-day variation, and eccs 
were generated. For each trunk-group size, the detection probabilities 
for given false-alarm levels were averaged over the other parameters. 
The results indicated that, as trunk-group size increases, so does the 
detection probability, but that for a false-alarm probability a = 0.10, 
even up to high-usage groups with 48 trunks, the average detection 
probability is less than 0.40. For high-usage groups with 24 or more 
trunks, a false-alarm probability of 0.2 provides the desired probability 
of detection. Since the small groups are less likely to be causing a 
problem on the final because of their smaller overflow, a false-alarm 
probability of 0.2 satisfied our objectives and, hence, will be used to 
specify the servicing thresholds for high-usage groups. 

To summarize, a high-usage trunk group is considered for servicing 
when c R > Ci + T, where T = k a a c - R , a = 0.20, and k a = 0.8416. The 
appendix gives an approximation to a c - H as a function of group size, 
data quality, and level of day-to-day load variation. 

4.3 Significant trunk requirement for high-usage groups 

Suppose that c/ trunks are in service and the true (expected) require- 
ment is cr. According to our model, Pr{cR ^ cr — T] » 0.8, where cr 
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is the estimated trunk requirement. This means that, with high prob- 
ability, at least c R - T trunks are truly required. The quantity c% = 
c K — T represents a conservative estimate of the true requirement c r 
and will be called the significant trunk requirement. Its use is discussed 
in Section 5.3. 

4.4 Summary of servicing thresholds 

Upper limits (thresholds) of observed average blocking and trunks- 
required estimates were developed above for grade-of-service and high- 
usage trunk groups, respectively. These thresholds are used to identify 
overload conditions on individual trunk groups while allowing for 
statistical variation in the estimates. 

V. DEMAND SERVICING ALGORITHM 

We now present a demand-servicing algorithm for network clusters. 
Our procedure consists of four parts: 

(i) Deciding whether servicing is required. 

(ii) Identifying groups in the cluster which are contributing to the 
problem (these groups are called candidates for servicing). 

( Hi) Determining augments for candidates. 

(iv) Deciding which candidates should be serviced. 
This sequence of decisions is executed in a cyclic order until the 
problem has been resolved. Each cycle results in either the decision 
that no action is required or that one of the candidate groups be 
serviced with its recommended augment. Details are given below. 

5. 1 Identifying clusters for servicing 

A network cluster is selected for servicing when its observed grade 
of service, as measured by the average blocking on the final group 
during the study period, is significantly greater than the 0.01 objective. 
This decision is made using the statistical test described in Section 4.1. 
If the measured blocking exceeds the upper limit B u , corrective action 
should be taken. 

5.2 Selection of candidates for servicing 

Using the trunk estimate thresholds developed in Section 4.2, indi- 
vidual high-usage groups in the cluster can be tested for overload 
conditions. Some, but perhaps not all, these groups will be selected as 
candidates for additional circuits by the procedure described below. 

As previously indicated, we recommended that the network be 
serviced at the lowest effective level, servicing only those high-usage 
groups that are contributing excess overflow to the final. These groups 
are chosen by starting at the highest level of the trunking hierarchy, 
the final, and proceeding downward into the cluster as follows. At each 
level of the hierarchy, only those undertrunked groups subtending 

TRUNK DEMAND SERVICING 855 



undertrunked groups at the next higher level are selected as candidates 
for servicing. Thus, we start at the (overloaded) final group and 
proceed downward until we find either a group with acceptable service 
or a primary high-usage group. This means that an overloaded primary 
high-usage (ph) group subtending an intermediate high-usage (ih) 
group with acceptable performance is not selected as a servicing 
candidate. 

5.3 Recommended number of trunks for candidates 

After a high-usage or final trunk group is selected as a candidate for 
servicing, another decision on the actual number of circuits to add 
must be made. This should depend not only on the estimate of trunks 
required, cr, but also on the following considerations: 

( i) The availability of additional f acuities for the group. 

(ii) Forecasts of requirements. 

{Hi) The servicing of subtending groups. 

However, specific information on the availability and costs of addi- 
tional circuits is not, in general, available in a mechanized fashion to 
a trunk servicing system such as tss. Therefore, the number of trunks 
planned or forecast for the imminent busy season, cf, may be used as 
a rough indication of the availability of facilities. However, we do not 
want to use cf as a strict upper bound on the number of trunks to be 
considered. Demand servicing should allow for unanticipated growth 
in the network while maintaining a near-minimum cost configuration. 

Conversely, suppose that the estimated (current) trunk requirement 
is significantly greater than the number of trunks in service, but less 
than that forecast for the current period (c/ + T< 6r< cf). Then one 
might be tempted to augment the group to its full forecasted require- 
ment, Cf, to anticipate future demand and to avoid both a service 
problem and the possibility of an additional augment in the near 
future. However, the forecast cf available to a system like tss is 
typically based on data at least a year old and may not accurately 
reflect demand in the near future, recent traffic transfers, and other 
relevant considerations. Hence, the practice of automatically servicing 
a group up to its forecast requirement cf is of questionable merit, 
especially in the context of demand servicing. 

Another factor to consider in the specification of a recommended 
trunk group size for groups that receive overflow traffic is the servicing 
of subtending groups. Adding trunks to subtending groups will decrease 
the offered load to the group under consideration; hence, fewer trunks 
will be required. If this reduced requirement, &r, still exceeds the 
acceptable level c/ + T, the recommended number of trunks, CR ec , is 
determined from this revised estimate by the method described below. 
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If c'r does not exceed the threshold, the group should not be serviced. 
Motivated by the considerations above, we recommend that an 
overloaded, high-usage trunk group (selected as a servicing candidate 
by the above rule) be sized to CR ec , where 

{cr if 6r < cf 
max(Cf, c%) if cr > Cf, 

and cr = Cr — T is the statistically significant trunk requirement. 

In other words, when the estimated trunk requirement exceeds the 
forecast, only the statistically significant number c% are recommended. 
However, if cr < cf < cr, then the forecast Cf should be implemented. 

We see in Section 5.4 that the selection of high-usage groups for 
servicing will be based on the magnitude of the reduction in overflow 
reaching the final when CR eL - trunks are implemented. Since this reduc- 
tion in overflow is related to the magnitude of the trunk group 
augment, consideration of the smaller, conservative estimate cr of the 
number of trunks required when Cr > cf will favor the selection of 
those groups for which additional facilities should be available. 

The recommended augment for final trunk groups is given in the 
servicing algorithm in Section 5.5. 

5.4 Selecting groups 

The decision to service the cluster is made when the measured 
average blocking on the final, B„, exceeds the threshold B u . Using the 
"top down" approach described in Section 5.2, we identify those high- 
usage groups that appear to be contributing to the overload condition. 
For each of these candidates for additional trunks, an (initial) augment, 
CRec — cj, is specified. 

Recall that a major objective of our demand servicing policy is to 
resolve the service problem at its source. This is accomplished by 
starting low in the network and working up into the cluster until the 
blocking on the final group is at an acceptable level. Specifically, we 
start by selecting an overloaded primary high-usage group, if one has 
been identified as a candidate, and augmenting it to its recommended 
level, CRec Since we would like to service as few groups as possible, we 
select, at each level of the trunking hierarchy, the candidate whose 
servicing will contribute the maximum reduction in load offered to the 
final. After this group is augmented, we determine whether additional 
action is required (Section 5.1), reexamine the candidacy of all groups 
affected by the augment (Section 5.2), and select the next group, if 
necessary. 

This procedure is described in detail below. 
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Fig. 5 — Cluster servicing algorithm. 

5.5 Servicing algorithm* (see Fig. 5) 

1. Service overloaded ph groups (if no ph groups were initially selected 
as candidates for servicing, or if none remain as candidates, go 
to 2): 

(a) For each (remaining) candidate ph group, compute A/, the load 
that will be removed from the final if the number of trunks in 
the group is increased from C/ to CR ec . 

(b) Choose the ph group with the largest AZ value computed in (a) 
as the group to be serviced. 

(c) Recompute the average blocking on the final, B'. If B' < B u , 
stop. Otherwise, recompute trunk requirements on all groups 
receiving overflow from the group just chosen, and reevaluate 
the candidacy of all high-usage groups affected by the servicing 
action. (These include all high-usage groups that receive over- 
flow from the group just serviced and all candidate high-usage 
groups in the same subcluster as the group just serviced.) 



* The algorithm described in this section assumes that only one level of ih groups is 
present in the network cluster trunking hierarchy. For more general networks, with ih 
groups overflowing to other ih groups, the algorithm can be generalized by stratifying 
the (overloaded) ih groups according to terminating office class. Step 2 is executed for 
each set of ih groups terminating at the same office class, starting with the lowest class 
and proceeding upward in the network. 
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2. Service ih groups (if no ih groups were initially selected as candi- 
dates or if none remain after 1, go to 3): 

(a) For each (remaining) candidate ih group, compute A/ as defined 
in la. 

(b) Choose for servicing the ih group with the largest A J value 
computed above. If none remain, go to 3. 

(c) Recompute average blocking on the final, B'. If B' < B u , stop. 
Otherwise, go to b. 

3. Service the final: Using the (revised) estimate of load offered to the 
final, compute the number of trunks required for 0.01 average 
blocking, stop. 

The algorithm terminates when either the servicing of subtending 
high-usage groups has lowered the final's blocking to an acceptable 
level (less than B u ) or the final itself has been serviced. 

VI. SUMMARY 

This paper has described a demand servicing procedure designed for 
implementation in the Trunk Servicing System (tss). Our approach 
consists of three parts: identifying network clusters which require 
servicing, locating specific groups within the cluster to be serviced, and 
determining how these groups should be augmented. 

The demand servicing procedure described here can be used to 
achieve the objective network performance in a cost-effective manner, 
allowing for such considerations as the statistical properties of the 
traffic measurements, the effect of servicing at different levels of the 
trunking hierarchy, and the availability of facilities. Following these 
procedures should reduce costly unnecessary network servicing activ- 
ities and ensure that servicing action is consistent with the network 
design objectives. 
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Table II — Curve fits to standard 
deviations of trunk estimates 
a(c) = bod) + b A (l)c 



Level of Load 

Variation Coefficient 

Low 0.578 0.019 

Medium 0.459 0.035 

High 0.305 0.053 
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played a fundamental role in the development of the demand servicing 
procedure described in this paper. 

APPENDIX 

Standard Deviation of Trunk Estimates for High-Usage Groups 

Using the method described in Ref. 2, the standard deviation ae H of 
high-usage trunk estimates was computed under the assumption that 
the trunk group is engineered to provide a specified economic load on 
the last trunk (eccs). In these studies, we examined trunk-group sizes 
from 3 to 240, eccs values from 6 to 24, traffic peakedness from 1.0 to 
4.0, and level of day-to-day load variation from low to high. It was 
assumed that hourly measurements of usage, peg count, and overflow 
(upco) were taken over a 20-day study period. 

The results indicated that, for each level of day-to-day load variation, 
the standard deviation is linearly related to the number of trunks in 
service but is rather insensitive to peakedness and eccs. A least- 
squares fit to the data for each level of day-to-day variation is accurate 
within one trunk for trunk-group sizes up to 240 trunks. Thus, the 
standard deviations can be considered to be functions of two variables, 
trunk-group size c, and level of day-to-day variation /. 

The linear approximations o(c) to the standard deviations, com- 
puted for each level of day-to-day variation, are given by 

o(c) = bod) + biiftc, 

where 6o(/) and &](/) were computed by a least-squares regression for 
/ = low, medium, or high and are given in Table II. 

Because Oc H is computed for 20-day samples, the factor \20/rid, 
where na is the number of days in the trunk study, is used to correct 
for non-20-day study periods. 2 

In general, 



Oc H = V20/n d [6o(/) + 6i(/)c]. 
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